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I . INTRODUCTION 

A. RESEARCH OBJECTIVES 

The aim of this thesis is to develop a model for a 
coordination support system (CSS) based on a newly synthesized 
coordination theory and the group decision support system 
(GDSS ) model proposed by Bui and Jarke (Bui and Jarke, 1986) . 
Current coordination theory is reviewed and drawn upon to 
develop a new approach to coordination which is then applied 
to reach a generic CSS design by establishing modifications to 
the GDSS model module by module. 

Additionally, the purpose of CSS, the expected benefits 
from their use, a sample rationale for developing such a 
system and the assumptions on which they are based are 
provided . 

B . BACKGROUND 

For many years computer hardware and software engineers 
have worked on achieving the smoothest and most efficient 
means of allocating scarce resources such as main memory, CPU 
time and peripherals. For this purpose, using various 
techniques such as process calls, hardware interrupts and 
input/output controllers have been exploited. Ideally, the 
machine coordinates all of its resources via an operating 
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system such that the user is presented with a tool that 
carries out all of the instructions provided. 

Even in large distributed computer systems the user has 
traditionally been provided with a "virtual" machine that is 
his alone despite the fact that there may be literally 
hundreds of other people using the system simultaneously. The 
operating system coordinates the machine resources so well 
that the user does not even realize other users exist. 

All of this has been accomplished in the absence of a 
coherent body of coordination theory (Malone and Crowston, 
1990) . Recent research in the fields of computer-supported 
collaborative work (Lim and Benbasat, 1990) , distributed 
artificial intelligence (Shaw, et al . , 1990) and 
organizational coordination methods (Crowston, 1991) indicates 
that machines will not only be used to coordinate their own 
activities, but the activities of users as well. 

Only recently have users seen the potential to coordinate 
their own activities using a machine as a tool. This is 
evidenced by the recent popularity of office automation tools 
such as electronic calendars, notebooks, spreadsheets and the 
like. Several activities seem to lend themselves well to 
machine coordination. Some examples are decision support, 
office automation, meeting support and battle management 
systems. Coordination theory will most certainly prove vital 
to the further refinement of existing coordination systems and 
to the development of new ones (Malone, 1990) . 
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C . METHODOLOGY 



In order to develop a new approach to the design of a CSS, 
a review of current work in the areas of coordination theory, 
coordination methods, command and control organizations, crew 
decision making and distributed artificial intelligence (DAI) 
is conducted. From this review, a new coordination theory is 
developed reflecting a systems design perspective. 

The utility of a CSS is discussed with respect to the 
expected benefits of such a system, particularly in the 
coordination of complex activities. One activity, the 
management of Anti-Aircraft Warfare (AAW) assets in a 
hypothetical carrier battlegroup (CVBG) serves as an example 
of a complex coordination activity throughout the paper. 

Once the need for a CSS is justified, the foundation for 
building such a system, the GDSS model proposed by Bui and 
Jarke, is reviewed to provide the reader with a reference for 
the more detailed discussion to follow. 

Finally, modifications to the GDSS model are proposed in 
order to form a generic CSS design. 

D. ORGANIZATION 

Chapter II provides a definition of coordination and a 
literature review covering coordination theory and other 
topics relevant to the development of coordination support 
systems. A new coordination theory is proposed for use in the 
design of CSS. 
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Chapter III discusses issues related to complexity in 
coordination and the strengths and weaknesses of human versus 
machine coordination of complex activities. 

Chapter IV reviews the GDSS model proposed by Bui and 
Jarke (Bui and Jarke, 1986) and describes the functions of 
each module. This chapter provides the reader with a 
reference for the discussion in the following chapter. 

Chapter V proposes modifications to the GDSS model that 
yield a model for a generic CSS. 

Chapter VI provides a summary and review of the material 
covered, discusses assumptions made in generating the generic 
CSS model and poses questions for further research. 
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II. COORDINATION AND ITS ELEMENTS 



A. COORDINATION 

Before entering a detailed discussion of what coordination 

is and what it is not, it is best to give the word meaning in 

common terms. Coordination, as defined by Mooney (1947), is 

nothing more than "the orderly arrangement of group effort, to 

provide unity of action in pursuit of a common purpose." Or, 

more simply, the act of coordination involves the harmonious 

sequencing of events in order to achieve a specific goal 

(Random House, 1987) . Coordination can be achieved by an 

individual, as in a well-coordinated athlete, or by groups, 

teams, crews and organizations. A less formal definition is 

given by Malone and Crowston (1990) : 

We all have an intuitive sense of what the word 
'coordination' means. When we attend a well run 
conference, when we watch a winning basketball team, or 
when we see a smoothly functioning assembly line we may 
notice how well coordinated the actions of a group of 
people seem to be. Often, however, good coordination is 
nearly invisible, and we sometimes notice coordination 
most clearly when it is lacking. When we spend hours 
waiting on an airport runway because the airline can't 
find a gate for our plane, when the hotel room we thought 
had been reserved for us is sold out, or when a company 
fails repeatedly to capitalize on innovative ideas its 
researchers develop we may become very aware of the 
effects of poor coordination. 
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B. COORDINATION SYSTEMS 



There are several types of computer systems that assist 
users in coordinating their activities. Some are designed to 
be used by a single user, while others are designed for 
multiple users. Some examples follow. 

1 . Man-Machine Coordination 

Perhaps the most obvious instance of man-machine 
coordination is that observed on modern assembly lines. In 
the case of automobile manufacturing, humans work side by side 
with robotic welders and other machines in order to produce a 
steady stream of vehicles to meet production schedules. 

On an individual level, many managers now make use of 
a decision support system (DSS) to coordinate their decision 
making processes. This computer-based system is typically 
constructed of a database, a model base and a user interface 
or dialogue. Via the dialogue a user stores and retrieves 
data; enters, updates, and modifies models; and manipulates 
data using the available models. The DSS provides a pattern 
or structure within which decisions are made. 

The DSS coordinates the decision-making process by 
providing the user with the means to define a problem or 
decision situation, describe the environment by choosing and 
tailoring a suitable model, access the pertinent data as a 
resource and solve the problem. Using an iterative process, 
the user can further refine the models and data to increase 
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the accuracy of the solution or solve "what if" queries. The 
common "spreadsheet" program is a simple example of this type 
of system. 

2 . Man-Machine-Man Coordination 

More often, however, it is necessary to coordinate the 
activities of a group of individuals. This capability falls 
in the arena of Group Decision Support Systems (GDSS) which 
allow groups to make decisions through the use of various 
decision techniques such as multiple-criteria decision methods 
(MCDM's) and consensus seeking algorithms. In addition to the 
f orementioned components of a DSS, the GDSS has a 
communication component which facilitates the involvement of 
more than one member in the decision-making process. These 
systems are very complex and often have complex electronic 
messaging schemes and sophisticated graphical displays. For 
these reasons they are usually managed by trained 
facilitators. Trained facilitators play a crucial 
coordination role in group decision making. The GDSS Co-oP, 
designed to aid groups in cooperative multiple-criteria 
decision making, is an example of such a system (Bui, 1987) as 
is the Interactive Management system (Biddle, 1991) . 

Office automation systems are also a common example of 
coordination systems. They are designed to aid in 
coordinating the activities of group members through various 
communication and scheduling tools such as e-mail and 
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electronic calendars. WordPerfect Office is an example of 
such a system (Coleman, 1991) . Unlike GDSS, current office 
automation systems tend to serve as media for solely text- 
based information exchange. 

Electronic Meeting Systems, such as that implemented 
at the University of Arizona (Nunamaker et al . , 1991), aid 
groups in structuring meetings and information exchange. 

Finally, battle management systems, which aid military 
commanders in tactical decision-making, are perhaps the 
ultimate coordination systems. Examples of existing systems 
are the Naval Tactical Data System (NTDS ) , which chiefly acts 
as a display of tactical information about radar and sonar 
contacts; and the Joint Operational Tactical System (JOTS) , 
which is a PC-based information system that displays and 
manipulates information about contacts worldwide and provides 
software for the manipulation of various other data. 

C. COORDINATION THEORY 

There are a variety of coordination theories in the 
literature and it appears that an easily distinguishable body 
of knowledge about coordination has not yet been established 
(Malone and Crowston, 1990) . Following are some of the more 
prevalent theories in the literature. 

Shaw et al . (1990) in their work on Distributed Artificial 
Intelligence (DAI) suggest that coordination is vital to 
multiple-agent problem solving. Since each participant in the 
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problem-solving process has only a local view of the effort 
put forth on the project, coordination with other agents is 
necessary to reach solutions efficiently. Furthermore, Shaw 
et al . review several mechanisms used to coordinate multiple- 
agents in the problem solving process including: 



• Coordination by Revising Actions - provides a plan of 
group actions such that all conflicts among group members 
are avoided. 

• Coordination by Synchronization - regulates and controls 
the timing of interactions among group members to achieve 
solutions . 

• Coordination by Negotiation - involves two-way 
communication to reach a mutually agreed upon course of 
action . 

• Coordination by Structured Group Mediation - involves the 
use of structured group processes like the nominal group 
technique and the brainstorming process to arrive at a set 
of group actions. 

• Coordination by Opportunistic Goal Satisfaction - employs 
the blackboard model for problem solving (Nii et al . , 
1989) wherein group members opportunistically contribute 
to the group solution process. 

• Coordination by Exchanging Preferences - applies game 
theory to determine how groups should interact to achieve 
globally satisfactory solutions. 



Each of these mechanisms is described in detail in his work. 

Orasanu (1990) , concluded in her research on aircrew 
decision-making that the use of certain types of communication 
aided the development of shared mental models (cognitive 
frameworks) , and thereby enhanced decision-making performance 



and coordination. 



Research by Stout et al. (1990) and Franz et al. (1990) 
revealed that certain behaviors including leadership, decision 
making, cooperation, communication and adaptability all led to 
superior crew coordination and performance. 

In their work on command and control nodes Monguillet 
(1991) and Levis (1991) model decision-makers using the Petri 
Net Formalism and describe coordination as the interaction 
between decision making nodes. 

Finally, Malone and Crowston (1990) propose a framework 
for analyzing coordination that decomposes the act of 
coordination into four component parts and their associated 
processes, see Table I. "Goals" correspond to the desired 
result of the coordinated effort. "Activities" are the 
individual actions that must be completed in order to achieve 
the desired "goal." "Actors" are the persons conducting the 
"activities." "Interdependencies" are the relationships 
between activities which govern their sequence. 

All of these theories contribute to the field of 
coordination theory but none suggest methods of designing CSS. 

D. ELEMENTS OF COORDINATION 

In this thesis, coordination is decomposed in order to 
yield elements that are easier for the system designer to 
understand and use in the design of a CSS. To this end, six 
elements of coordination are proposed and described below. 
They are (i) outcome, (ii) environment, (iii) resources, (iv) 
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Table I: COMPONENTS OF COORDINATION 



Components of Coordination 


Associated 
Coordination Process 


Goals 


Identifying Goals 


Activities 


Mapping Goals to 
Activities 


Actors 


Selecting 
Actors /As signing 
Activities to Actors 


Interdependencies 


Managing 

Interdependencies 



time, (v) schedule and (vi) communication. Some of these 
elements have been written about previously by other authors 
but this set of six elements provides the CSS designer with a 
more designer-friendly framework. 

An outcome, or goal, is the desired result of the 
coordinated event, its key objective. For an outfielder, it 
may be catching a fly ball; for an F/A-18 crew, it may be a 
successful bombing mission or for a construction crew, it may 
be the completion of a new building on schedule. Whatever the 
outcome, it must be identified before it can be coordinated. 
On a computer the outcome would have to be selected from 
perhaps several outcomes listed on a menu before the machine 
could proceed with the coordinating process. Malone and 
Crowsten (1990) use the term "goal" in place of outcome. 
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The environment must then be evaluated for conditions that 
may effect the coordination process. These conditions 
include, but are not limited to weather conditions, economic 
conditions, political conditions, even traffic conditions. It 
is important to note that the environment can not be 
controlled or directed by the coordination process but, in 
contrast, it can impact the coordination process in many ways. 
Environmental conditions include any externality that could 
effect the coordination process. Environmental sensors can be 
linked to a computer providing continuous information on 
elements of the environment important to the coordination 
process. Cheng (1983) supports the importance of the 
environment in the coordination process. 

Resources are those elements which play an active role in 
achieving the selected outcome. In the previous examples they 
may be the number of outfielders, the number of bombs or the 
number of bulldozers and cranes. There are often many 
resources that must be considered in complex coordination 
processes, e.g. in landing a plane. Before landing, a myriad 
of resources must be checked such as the electro-hydraulic 
system, landing gear, flaps, rudders, tire rotation, 
availability of a runway etc. Without any one of these the 
successful achievement of the desired outcome may be severely 
impaired. Resources can also be linked to, or make use of, a 
computer to receive information and provide feedback. 
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Resources correspond to "actors" in the Malone and Crowsten 
(1990) framework. 

Time is the fourth key element in the coordination 
process. The selected outcome must be assigned a time for 
completion or maximum duration, i.e. the outcome must have a 
due date or deadline. It may be determined that there is not 
enough time to achieve a particular outcome without 
sacrificing some intermediate steps, perhaps safety checks, or 
overriding default limits. If this is the case, a decision 
must be made to either cease or continue the coordination 
process. In some cases the deadline will be "as soon as 
possible" but this must be known for the coordination process 
to continue to the next step. Computers monitor the passage 
of time using internal clocks and can be programmed to 
generate alerts when certain time constraints are not met. 

Once the outcome is determined, the environment and 
resources checked and a deadline assigned, a schedule can be 
generated that will guide the individual or group members 
toward the completion of the coordination process. In the 
case of a group or crew coordinated event, the schedule will 
have role specific task assignments for each person (resource) 
and make provisions for assignments to be carried out in 
parallel where possible or necessary. Schedule generation 
involves managing the "interdependencies" of Malone and 
Crowston (1990) . 
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Finally, communication of the schedule, and feedback on 
the progress of the participants through the schedule, is 
required to effectively implement the coordination process. 
Aircrews commonly use checklists to help them through the 
coordination process. One member reads the checklist while 
the others verify that certain conditions exist then respond 
with verbal confirmations of compliance. Computers can 
communicate via network linkages with other computers and data 
sources (Fitzgerald, 1990) . Without communication, the 
coordination process could not take place, in fact, some 
consider communication to be the key to coordination (Stoner 
and Freeman, 1989) . 

All of these six elements must be considered and built 
into the design of a coordination support system to make it 
effective . 

E. THE ROLE OF COMMUNICATION IN GROUP COORDINATION EFFORTS 

The importance of smooth communication in the coordination 
process cannot be overstated, it is fundamental to group work 
(Lim and Benbasat, 1990) . Often environmental conditions and 
resources can be overlooked and time and schedule requirements 
can be adjusted but, without communication, the entire process 
will become ineffective. 

1 . Communication Dimensions 

Group communication situations can be classified 
according to four different dimensions (Jarke, 1986) : (i) 
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spatial distance, (ii) temporal distance, (iii) centralization 
of control and (iv) degree of cooperation. 

Spatial distance refers to the actual distance between 
group members. Are they meeting in the same room or are they 
widely distributed and communicating via telephone, radio, 
computer, or videoconference? 

Temporal distance refers to the time between inputs to 
the communication process. Are group members communicating 
one immediately after the other or are their inputs separated 
by days, weeks or months? 

Centralization of control refers to the level of 
equality of the group members. Does one member have more 
power than the others or are all of their communications 
considered of equal importance? 

Degree of cooperation refers to the communication 
style of the group. Are they striving to achieve a common 
goal or are they negotiating or debating a point? 

These four dimensions must be considered by a CSS 
designer if his system is to be successful. For example, a 
CSS in which the resources are widely separated (spatial 
distance) must provide a means of communicating between the 
various remote locations. Also, if the CSS is to support 
asynchronous input by resources (temporal distance) , the 
designer must implement the additional communication 
capabilities . 
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2 . Time-Space Taxonomy 
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Figure 1 A Taxonomy of Groupware (Ellis et al . , 1991) 

Ellis et al . (1991) provide a diagrammatic taxonomy 
(Figure 1) expressing the differences between various types of 
"groupware" (software designed for use in group systems) . The 
simple two-by-two matrix distinguishes between distributed and 
local group systems on one axis and between real-time and 
asynchronous group systems on the other. In the upper left 
quadrant, one would find an Anti-Aircraft Warfare CSS, in the 
lower left, a nuclear power plant CSS, in the upper right, a 
nationwide telecommunications trouble shooting CSS and in the 
lower right, a project management CSS. Each type of system 
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has its own communication requirements and a comprehensive CSS 
should be capable of exploiting them all. 
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III. INHERENT COMPLEXITY IN COORDINATION: THE CASE OF 
COORDINATING ANTI-AIRCRAFT WARFARE 

A . BACKGROUND 

1. A Brief Description of Anti-Aircraft Warfare 

Anti-Aircraft Warfare (AAW) is a highly complex 
activity requiring sophisticated command, control and 
communication systems and the precise coordination of many 
widely dispersed participants. A simplified AAW scenario 
involving only the use of fighters and other tactical air 
assets will serve to illustrate the level of complexity 
frequently encountered in similar situations. 

In order to provide the carrier battle group (CVBG) 
with an appropriate defense against hostile aircraft and anti- 
ship missiles, the Anti-Aircraft Warfare Commander (AAWC) must 
be able to detect, intercept and destroy enemy aircraft 
capable of firing missiles (missile platforms) . In the case 
of some of the most threatening air-launched anti-ship cruise 
missiles this translates into a requirement that the AAWC have 
control of fighter aircraft resources with which to create a 
barrier capable of destroying airborne enemy cruise missile 
platforms before they launch their weapons. 

Though the AAWC is not normally located aboard the 
aircraft carrier, he has the authority to direct the launch of 
alert aircraft in order to fulfill his requirements. Upon 
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doing so, the AAWC becomes responsible for the aircraft until 
it is safely back on deck. This includes keeping aware of 
vital systems status, weapons loadout, pilot condition and 
fuel status. The AAWC instructs the pilot on the direction 
and speed to the intercept point, the point at which the 
fighter could conceivably launch missiles to intercept the 
incoming hostile missile platform, what to do when he arrives 
at the intercept point, how long to stay there and when to 
return. Should a fighter fail to reach the intercept on time, 
the hostile aircraft could launch its cruise missiles 
unmolested and the liklihood of severe damage to the CVBG 
would increase greatly. It is this consequence that the AAWC 
must strive to prevent . 

Based on the perceived threat at any given time the 
CVBG adopts a specific readiness posture. The AAWC designates 
the number of aircraft of each type (fighters, tankers, 
airborne early warning (AEW) aircraft) to have in various 
alert states based on the current readiness posture. 

Accurate environmental inputs are critical to success. 
Among these are wind speed and direction, atmospheric 
conditions, cloud conditions, visibility, humidity, rain, 
snow, proximity to land, the current Rules of Engagement 
(ROE), precise position of the CVBG etc. Often these factors 
determine the ability to launch and land aircraft, sensor 
performance, aircraft engine performance, the ability to 
engage a target etc. Ignorance of these inputs may cause the 
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AAWC to needlessly endanger the safety of an aircrew or even 
the CVBG or cause an adverse political incident. 

Initially, the AAWC is concerned with detecting enemy 
aircraft at a distance great enough to allow time for him to 
respond. He has various assets (resources) at his disposal to 
do this including but not limited to intelligence, long range 
air search radar, and AEW systems. Once an enemy is detected 
and classified, the time to weapons release must be 
calculated. This time is based on the position of the enemy 
relative to the CVBG, the classification and probable loadout 
of the enemy, the enemy course and speed, and the CVBG course 
and speed. 

Next, the AAWC must determine the appropriate aircraft 
to conduct the intercept. Indeed, there may already be an 
aircraft airborne that could do the job. Consideration must 
be given to pilot fatigue, fuel status, equipment status etc. 
If the decision is to conduct the intercept with an aircraft 
that was returning to the carrier, it may be necessary to 
launch a tanker to provide in-flight refueling services to the 
returning aircraft before sending it out again. If the 
intercept must be made quickly due to a late detection, the 
increased fuel burn rate of the interceptor racing to the 
intercept must trigger the launch of a tanker as well. Timing 
is critical since battlegroup survival may be at stake. 

Data regarding the weapons loadouts, cruise speeds, 
attack speeds, dash speeds, ranges, sensors, tactics etc. of 
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all enemy aircraft must be easily accessible. Likewise, 
corroborating historical data should also be accessible. 
Similar data about all friendly aircraft must also be 
maintained including alert status, engagement status, and 
launch delay status. 

During periods of sustained high threat the AAWC 
promulgates a schedule that directs the employment of aircraft 
toward the end of CVBG defense. The schedule provides for 
regular launch and recovery of aircraft, their assigned 
stations, fuel requirements, and action to be taken if an 
enemy aircraft is detected. 

Communication channels between the AAWC and all 
airborne friendly aircraft must be maintained in addition to 
the channel between the Battle Group Commander and the AAWC so 
that vital information can be shared. Often this is done 
using encrypted signals. 

2 . Anti-Aircraft Warfare and the Elements of Coordination 

A rapidly changing environment can cause the 
coordination process to become complex by forcing the 
coordinator to reevaluate earlier choices and determine if 
they remain valid. It may also impede the initial decision to 
take action at all. For example, consider the AAWC's choice 
of the number of aircraft to have in a particular alert 
status. Should the political environment change, the 
corresponding threat readiness level of the entire CVBG may 
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change necessitating a change in the AAWC's alert 
requirements . 

Having a large number of resources to monitor can also 
have a dramatic effect on the complexity of coordination. 
Monitoring a diversity of resources is a time consuming and 
confusing problem often involving parallel processing. For 
example, it is not uncommon for the AAWC to be monitoring 
three communication channels (AAWC-CVBG Commander /AAWC- 
Aircraft/ AAWC-AAW Capable Surface Ships) , four displays 
(NTDS/Status Boards/Navigational Charts/Air Charts) and the 
status of dozens of aircraft. The volume of information 
flowing to one person often can not be assimilated quickly 
enough which results in information loss. 

When events need to be coordinated on a real-time 
basis rather than over a long time span, the coordination 
process is more complex. This is due to a distinct lack of 
time to follow the decision processes necessary to make or 
modify schedules . Often the achievement of a particular 
outcome is desired in a relatively short time span, as in the 
proper handling of a surprise missile attack. There is little 
time during an emergency to coordinate group actions, think 
about what must be done and issue instructions. To improve 
coordination, pre-planned responses to particular situations 
are developed and practiced regularly so that they may be 
performed swiftly and safely when required. 
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As the interdependence of events increases, so does 
the complexity of the coordination process (Cheng, 1983) . The 
communication overhead required to monitor interdependencies 
often slows the coordination process and the generation of 
schedules . For example, the choice of an aircraft to conduct 
an intercept is dependent on the type of enemy aircraft, its 
loadout, speed and range, the time to weapons release 
distance, the availability of fighters and tankers, their 
loadout, systems status etc. Highly interdependent events 
form virtual bottlenecks in the coordination process, see 
Figure 2. See Malone and Crowston (1990) or Crowston (1991) 
for a treatment of the types of interdependence. 
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Difficulty in communication can also impede the 
coordination process by halting the flow of information 
between group or crew members. When information flow is 
disrupted it becomes impossible to coordinate interdependent 
events and to monitor resources or the environment. Without 
radio contact, the AAWC would find it nearly impossible to 
coordinate the actions of his many resources for any 
reasonable length of time. In practice, he is confined to the 
use of pre-planned responses. 

B . HUMAN FACTORS 

These were just a few isolated samples of causes of 
increased complexity in the coordination process. The reality 
is in fact even more complex. All of this complexity can 
cause a coordinator to become overwhelmed which ultimately 
leads to failure to achieve the desired outcome. 

Typically decision-makers become overwhelmed when they are 
unable to assimilate information at a high enough rate or they 
do not know what to do with the information they have. In 
essence, they become input/output (I/O) bound and are unable 
to process the information they are receiving. When this 
happens, decisions are made on a primarily subjective "gut 
feeling" basis and therefore can be partially or wholly 
illogical . 
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Humans can also be tired, bored, anxious, impatient, 
angry, ill etc. and their performance is often affected by 
their current disposition. 

Battle management in a multi-threat environment is often 
an overwhelming situation. A ship tasked with defending 
itself against hostile surface, air and submarine attacks 
simultaneously must collect, evaluate and make decisions based 
on an enormous amount of information; all on a real-time 
basis. The entire process is often described as ’’managed 
chaos” and requires a well-practiced team to prevent a 
disastrous failure in the defense. 

C. EXPECTED BENEFITS OF COORDINATION SUPPORT SYSTEMS 

Given that events can become extremely difficult to 
coordinate and the fact that they often must be coordinated 
despite their complexity, avenues of alleviating some or all 
of the difficulty must be sought. Since machines have 
capabilities to complement or augment those of humans, they 
are a logical choice. 

First, they are capable of being programmed with the 
routines to handle a large number of desired outcomes. This 
relieves the human coordinator of the responsibility for 
maintaining checklists and memorizing procedures. The 
routines will be executed smoothly and efficiently without 
skipping steps. Additionally, these routines are infused with 
the knowledge of experts in the specific field and would 
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therefore prescribe actions that the novice may overlook or 
deem unimportant. 

Second, machines are capable of continuously monitoring 
vast amounts of incoming data from environmental sensors. The 
machine can be programmed to take specific actions when 
certain limits are triggered by the incoming data flow. 
Machines are rarely "overwhelmed" by excessive data flow and 
therefore are not as prone to information losses. 

Third, machines can monitor resources continuously and 
tirelessly. A machine will not become tired, bored, angry or 
ill. 

Fourth, a machine can process data on a real time basis 
without becoming confused by data flow. Program execution 
rates far outpace the rate of human cognition in routine 
information processing. 

Last, machines can manage and provide for communications 
between members of a group or crew, even on a decentralized, 
asynchronous basis. NTDS is an existing example of this 
technology . 

Given these capabilities, it appears that a coordination 
support system could indeed simplify the coordination process 
by off-loading many responsibilities of the human coordinator 
thus allowing him to concentrate on the more important parts 
of the process. The remainder of this thesis proposes a model 
on which to base the design of a generic CSS. 
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IV. THE FOUNDATION 



A. THE GDSS MODEL 

Because the design of the GDSS is so flexible and it 
already provides many of the functions necessary to implement 
a coordination support system, the current GDSS model will 
form the foundation for our further study. Sprague and 
Carlson (1982) proposed a fundamental DSS architecture 
composed of three main components: (i) the dialogue manager, 
(ii) the data manager and (iii) the model manager. Each was 
discussed briefly earlier. Bui and Jarke proposed an 
additional fourth component fundamental to a distributed GDSS, 
the communication manager. Each component will be examined in 
detail below. 

1 . The Dialogue Manager 

The dialogue manager provides the user interface 
function for the GDSS. As an interface feature, there are 
several possible styles. Among them are: (i) command 
language, (ii) menu, (iii) formatted form and (iv) prompt 
(Awad, 1988) . The dialogue of any given system may use one or 
more of these styles to interface with the user and allow him 
to make use of the database, model management and 
communication functions of the GDSS. 
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2 . The Data Manager 

The data manager provides the functions of a database 
and a database management system (DBMS) for the GDSS. 
According to Kroenke and Dolan (1988), a generic DBMS performs 
the following functions: (i) store, retrieve and update user 
data, (ii) store, retrieve and update meta-data, (iii) enforce 
data integrity rules and constraints, (iv) enforce security 
constraints, (v) provide coordination and control facilities 
for multi-user processing and (vi) provide facilities for 
system backup and recovery. In addition, the DBMS must be 
capable of handling both internal and external data. All of 
these functions are required by the GDSS and the user can 
invoke, setup or make use of them through the dialogue. 

3 . The Model Manager 

The model manager gives the user the ability to 
explore a problem completely by developing and comparing 
alternative solutions (Sprague and Carlson, 1982) . There is 
a model base, which is composed of a set of analytical models, 
equations and algorithms and a modelbase management system 
(MBMS) which provides DBMS-like functions for the model base. 
Four basic functions of the MBMS include: (i) generation of 
models, (ii) restructure of models, (iii) update of models and 
(iv) report generation and inquiry (Sprague and Carlson, 
1982) . The models have access to data in the database via the 
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DBMS and can generate solutions to inquiries posed on a 
regular or ad hoc basis. 

4 . The Communication Manager 

Finally, the communication manager proposed by Bui and 
Jarke is composed of four main parts: (i) the group norm 

constructor, (ii) the group norm filter, (iii) the invocation 
mechanism and (iv) the IDSS-GDSS information formatter. 

a. The Group Norm Constructor 

The group norm constructor is used to define group 
members, communication channels and group decision rules. 
This is achieved through a group leader or facilitator 
collecting information according to a checklist. User 
identification, communication methods and decision models are 
specified explicitly so that all users and the system have a 
common reference. 

b. The Group Norm Filter 

Once this information is entered into the group 
norm constructor, it is compiled into a set of instructions 
called the group norm filter. The purpose of the group norm 
filter is to enforce the protocol defined using the 
constructor. Specifically the group norm filter performs 
three functions: (i) grants access to users based on 

identification and password and warns users of upcoming 
decision deadlines, (ii) monitors all user data transfers, 
ensuring they are in accordance with the established protocol 
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and (iii) monitors the computation of the group decision 
results by the model manager. Via these functions, the group 
norm filter ensures the decision process proceeds as defined. 

c. The Invocation Mechanism 

In order to provide a degree of flexibility to the 
functions of the communication manager, the invocation 
mechanism was designed to enable the group to request and make 
modifications to the protocol defined using the group norm 
constructor. In this manner the protocol can be partially 
redefined during the decision process; to add another group 
member for instance. Since members must approve changes 
before they are made, the invocation mechanism also provides 
a means of notifying and convening members to make such a 
decision . 

d. The IDSS-GDSS Formatter 

Finally, the IDSS-GDSS formatter enables the GDSS 
to communicate with other IDSS in a distributed system by 
supplying the appropriate data conversion protocols. Without 
this ability, a distributed GDSS would not be possible. 

B. A COMPARISON 

To alleviate some of the confusion caused by the varied 
terminology used in discussing coordination theory and 
systems, Table II provides a simple comparison. 
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Table II COMPARISON OF TERMS 



MALONE/CROWSTON 


CSS 


GDSS 


GOALS 


OUTCOMES 


GROUP NORM 
CONSTRUCTOR 




ENVIRONMENT 




ACTORS 


RESOURCES 


GROUP NORM 
CONSTRUCTOR 




TIME 


GROUP NORM 
CONSTRUCTOR 


ACTIVITIES/ 

INTERDEPENDENCIES 


SCHEDULE 


GROUP NORM 
FILTER/ 
INVOCATION 
MECHANISM 




COMMUNICATION 


GROUP NORM 
CONSTRUCTOR/ 
INFORMATION 
FORMATTER 



C. SUMMARY 

Having outlined the component structure of a generic GDSS 
and discussed the functions of each part, it is easy to see 
how the generic GDSS will provide a suitable foundation for a 
coordination support system. In order to construct a generic 
CSS, however, some modifications must be made to each of the 
components . These are the subject of the next chapter. 
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V. MODIFICATIONS TO THE MODEL 



A. THE NATURE OF A COORDINATION SUPPORT SYSTEM 

Before delving into the design specifics of a CSS, a 
discussion of how a CSS would be used might greatly assist the 
reader in understanding the design rationale proposed in later 
sections of this chapter. 

1 . Selection Phase 

Faced with the responsibility for coordinating a 
particular activity, the user would begin his interaction with 
the CSS by selecting from a menu or outcome library the 
particular outcome that corresponds to the activity he wishes 
to coordinate, e.g. intercept a hostile aircraft etc. Each 
CSS would have a domain similar to that found in expert 
systems (Sol, 1987) . The domain is the description of the set 
of outcomes the CSS is designed to handle. This initial phase 
is known as the selection phase. Here the user selects an 
outcome which in turn invokes a specific program branch that 
deals with the outcome the user specifies. 

2. Resource Allocation Phase 

Once an outcome is selected, an activity specific 
program is invoked. The user will then be prompted to give 
the system necessary information about resources, 
environmental inputs, time constraints and communication 
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channels. The user must define such items as the number of 
human resources and their roles, non-human resources, 
environmental inputs, the deadline for completion of the 
outcome and the communication channels for all resources and 
environmental inputs. Depending on the CSS some of the 
resources, environmental inputs and communication channels may 
have default values and others may be permanently assigned. 
The important issue is that the CSS be able to communicate 
with all resources and receive pertinent environmental 
information. The entry of this information concludes the 
resource allocation phase. 

3. Schedule Generation Phase 

Information entered during the resource allocation 
phase is now passed to the schedule generator which uses 
optimization models, heuristic and mathematical analysis and 
logical algorithms to generate resource specific and 
contextually sensitive schedules for use in coordinating the 
activity requested by the user. Generic models and algorithms 
would be part of the CSS modelbase whereas activity specific 
models would be a component of the activity specific program. 

Each schedule would be resource specific and composed 
of schedule elements, or tasks, to be completed by a specific 
deadline. Only those items that the machine is not capable of 
doing would be part of the schedule. Warnings would be 
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generated whenever insufficient time precluded completion of 
the coordination process. 

4 . Output Generation Phase 

The CSS would now take the output from the schedule 
generation phase and communicate it to the resources 
previously defined. These outputs may take the form of 
electro-mechanical instructions to devices capable of digital 
control, messages sent via network or modem to remote human 
resources, printed instruction sheets, screen instructions, 
alerts or even synthetic voice commands. The output is the 
link by which the CSS directs the actions of the resources in 
order to coordinate the desired activity. 

5 . Monitoring Phase 

Finally, the CSS would monitor the assigned 
communication channels for feedback from resources indicating 
completion of schedule elements. The CSS would also provide 
alerts to the resources as appropriate indicating impending 
deadlines and/or overdue schedule elements. 

An additional feature of the system would be a 
mechanism to change elements of the resource allocation phase 
at any point in time so that new resources or inputs could be 
added or old ones deleted. 

B. OVERVIEW 

In summary/ the user first selects a desired outcome, to 
intercept a hostile aircraft for instance. He then defines 
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the environmental inputs (wind speed, ship's navigational 
inputs, radar etc) and the communication path the CSS is to 
make use of to receive all pertinent data (COMM 1) . Next he 
defines the various resources such as the AAWC, airborne 
fighters, alert fighters on deck, tankers, AEW aircraft etc 
and the communication channels assigned to them (e.g. video 
display, NTDS, voice radio) . Finally a desired time of 
intercept, or in this case a range is sometimes more 
appropriate, is provided to the system. To assist the user in 
the resource allocation phase, the system would provide 
default values and the capability to save previous setups. 

The CSS would subsequently generate directions in the form 
of schedules for each resource involved in the intercept 
process based on previously programmed heuristics and the 
input it receives on the communication channels it monitors. 
The system can even be programmed to request data it needs to 
complete its analysis. Once the schedules are communicated, 
the CSS would monitor resource communication channels for 
feedback on progress through the schedule (interceptor 
launched to station One Two Delta etc) . 

C. THE GDSS MODEL REVISITED 

From the previous discussion, the reader can see that the 
GDSS model described in Chapter IV provides a logical 
foundation for modeling the proposed CSS since it already 
provides many of the required functions. Required 
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modifications to the GDSS model are the subject of the 
following sections. 

1. The Revised Dialogue Manager 

The functions of the GDSS dialogue manager would not 
differ much from those of the usual GDSS user interface: (i) 

provide the user with a representation of the system and (ii) 
provide the user with a means of controlling the system 
(Sprague and Carlson, 1982) . A good dialogue is essential to 
the system for if it is unfriendly or obscure, the system may 
be rejected entirely by the user (Awad, 1988) . 

Specifically, the dialogue would need to enable the 
user to perform the following functions: 

• Select an outcome from a list or library of supported 
outcomes . (Menu) 

• Define environmental inputs, resources, time constraints 
and communication channels. (Formatted Form) 

• Respond to alerts, error messages and acknowledgements. 

(Prompt) 

• Issue instructions to the database, modelbase and 
communication managers via the invocation mechanism. 

(Command Language) 

As noted parenthetically above, the dialogue style would be a 
mixture of the common forms. All of the styles are within 
current state-of-the-art dialogue design capabilities. 

The display of data, whether textual or graphical, is 
another function of the dialogue manager that must be 
carefully implemented to ensure user acceptance of the CSS. 
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2. The Revised Data Manager 

The data manager must be capable of fulfilling all of 
the requirements delineated in Chapter IV. Of paramount 
importance is the ability to support multiple environmental 
inputs and resources in a distributed CSS. This implies 
several capabilities including: 

• Send and receive data to and from multiple resources 

• Receive data from environmental inputs 

• Encrypt/decrypt data for security 

• Store, retrieve and update internal data 

• Manage data buffers and queues 

• Interface with dialogue manager for the display of data 

• Store default values and communication setups 

• Store transaction reports for post-action analysis 

As can be seen, the data manager provides many vital functions 
to the CSS and the design must be correspondingly robust. 

It is conceivable that several resources may desire 
access to data maintained in the CSS which implies that the 
generic CSS data manager be capable of managing a distributed 
database. Many issues related to data security and control 
are involved in designing a distributed database, see Kroenke 
and Dolan (1988) for a thorough discussion. 
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3. The Revised Model Manager 



The model manager is to perform the function of the 
schedule generator and therefore will be designed to manage 
schedules, schedule elements and their related 
interdependencies. The four basic functions then become 
schedule generation, restructure, update and report 
generation/inquiry . 

The schedules are to be coded in the same fashion as 
the heuristics coded in the knowledge acquisition process used 
in expert systems development (Hayes-Roth, 1983) . Experts in 
the fields of interest are interviewed and their knowledge is 
captured as a set of heuristic rules. In the CSS case, these 
rules would reflect the best way to coordinate a particular 
event. Restructure and update of the rules must be possible 
to accommodate differences between the ideal "classroom" 
situation and the often less-than-ideal "real-world" 
situation . 

Additionally, the model manager must provide for the 
interface with the dialogue, data and communication managers. 
Data from the environmental inputs and resources must be 
available to the model manager so that it may monitor the 
coordination process. 

Schedules for AAW might include one for intercepting 
hostile aircraft, one for downed aircraft search and rescue 
(SAR) , one for launching and maintaining a defensive barrier, 
etc . 
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4. The Revised Communication Manager 

a. The Group Norm Constructor 

The group norm constructor (GNC) provides the means 
for defining the coordination elements appropriate to each 
outcome. Once an outcome is selected, a form would appear on 
the screen with blanks to fill in regarding environmental 
inputs, resources, communication channels, and time 

constraints. Default values would be listed where 

appropriate. Once all inputs were provided the communication 
manager would send the data to the schedule generator for 
compilation . 

b. The Group Norm Filter 

The group norm filter grants access to the CSS, 
enforces the protocol defined in the GNC and monitors the 
schedule generation process. This means that all 

communications take place only between the elements specified 
and on the channels defined in the GNC. 

c. Information Formatter 

(1) Environmental Input Data Conversion. The 
variety of possible input types requires that a module be 
specified for the purpose of converting various input types 
into data streams useable by the model manager and the data 
manager. Examples include analog to digital conversion and 
data formatting. This module will vary in size and complexity 
with the domain of the associated CSS. 
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(2) Resource Monitor Data Conversion . Since 
resources also communicate directly with the CSS, data 
conversion similar to that explained above must also take 
place for both inbound and outbound data streams. Depending 
on the resource, the CSS may send instructions in the form of 
text or digital signals for example, 
d. Invocation Mechanism 

The invocation mechanism is designed to be able to 
modify the protocol defined in the GNC after the coordination 
process has begun. For instance, suppose an interceptor loses 
its ability to communicate or has another mission critical 
failure, the invocation mechanism would allow the user to 
interrupt the coordination process, enter information on a 
substitute aircraft, and re-initiate the process. In a 
similar fashion communication channels and environmental 
inputs could be changed, added or deleted. 
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VI. SUMMARY AND REVIEW 



A. SUMMARY 

In developing a fresh design for a computer system it is 
prudent to first survey existing systems that have common 
design features. This study examined the designs of DSS, 
GDSS, OAS and EMS technologies to determine their suitability 
as a foundation for developing a generic CSS. None of these 
designs had all of the required features but one, the GDSS, 
came very close. 

Next, the activity of coordination was studied and 
decomposed into its elements of: outcome, environment, 
resources, time, schedule and communication. It was 
determined that each element must be built into the CSS at the 
design stage before proceeding. 

The vital role played by communication in the coordination 
process was discussed. Noted were the key communication 
dimensions spatial distance, temporal distance, centralization 
of control and degree of cooperation. A time-space taxonomy 
of group systems was provided to lend perspective. 

A great many factors can increase the complexity of the 
coordination process. Examples were provided showing it is 
likely that as the environment changes, the number of 
resources varies, the time to coordinate events decreases, the 
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interdependence of events increases and the difficulty of 
communication increases, events become much more difficult to 
coordinate . 

Human factors such as subjectivity, inability to parallel 
process, slow data assimilation and irrationality can also 
affect the coordination process. 

Some advantages of a CSS were described such as faster 
information processing, parallel processing, resource 
management capabilities, automated input from several sources, 
and quality of information output. 

As a starting point, the GDSS architecture proposed by Bui 
and Jarke was used to describe the foundation for a CSS. Each 
component of the dialogue manager, data manager, model manager 
and communication manager was described in order to give the 
reader a common reference point when discussing the design of 
the proposed CSS. 

Before outlining the structure of the CSS a five phase 
framework was developed to provide a system description. The 
phases were labelled selection, definition, schedule 
generation, output and monitor. A discussion of the five 
phases helped the reader understand the function and scope of 
a CSS. 

Finally, the actual modifications to the GDSS model 
required to design a generic CSS were examined component by 
component. Each modification was proposed to better support 
the coordination process and the development of a CSS. 
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B. JUSTIFICATION 



To undertake the actual design and implementation of a CSS 
would require an investment proportional to the size and scope 
of the desired system. In order to establish the utility of 
a CSS, and therefore to help justify the investment, it is 
useful to analyze system requirements with respect to the six 
elements of coordination. The answers to some basic questions 
will help to begin the analysis: 



• To what extent are the outcomes of the proposed CSS 

recurring requirements? The more recurring the 

requirement, the more often the system will be used. 

• To what extent can environmental inputs provide automated 
input to the system? The greater the number of automated 
inputs, the less data acquisition and assimilation 
required of the human coordinator. 

• To what extent can resources be controlled, messaged 
and/or provide feedback electronically? The closer the 
control, the more efficient the coordination. 

• What are the time constraints of the desired coordination 
process? The shorter the allowable time to complete the 
coordination process, the more effective the system. 

• To what extent can the coordination process be 
premeditated, i.e., is there a "best" way to sequence the 
schedule elements? The more it can be premeditated, the 
greater the effectiveness of a CSS. 

• To what extent can communications be established between 
environmental inputs, resources and the CSS? The greater 
the number of linkages, the greater the utility of the 
system . 



From the answers to these questions a general feel for the 
utility of a proposed CSS can be sensed. If it is 
subsequently determined that the proposed system is worth the 
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estimated investment, there are several possible benefits of 



its implementation. Among them are: 



• Faster Coordination of Events - due to the computational 
speed of the computer, the rapidity of electronic 
communications and the increased rate of data 
assimilation . 

• More Efficient Coordination of Events - due to the reduced 
amount of time and effort required to prepare and 
coordinate an event when using a CSS. 

• More Effective Coordination of Events - due to the 
incorporation of expert knowledge, the schedule generated 
for execution will be of higher quality than one generated 
by novices. 

• Improved Analysis of the Coordination Process - due to the 
ability to save all system transactions for later 
retrieval and review. 

• Improved Allocation of Slack and Scarce Resources - due to 
the automated monitoring of resource capabilities. 



These are only a few of the more obvious benefits of 
implementing a CSS, others, including the more efficient use 
of resources and the development of competitive edge, 
certainly exist. Each application developed would most likely 
have a unique set of benefits. 



C. ASSUMPTIONS 

Certain assumptions were made in the process of developing 
a generic CSS design. Among them that there is a best way to 
coordinate an event and, that expert knowledge can be acquired 
and reduced to code for implementation in a CSS. The first 
assumption implies that, given a set of selection criteria, an 
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expert or team of experts could select from a set of possible 
sequences of schedule elements, the sequence that is least 
wasteful of time, resources, and effort. The second 
assumption is supported by many works in the field of expert 
systems and has been the guiding principle in their 
development (Davis, 1982) . 

D. FURTHER RESEARCH QUESTIONS 

The theoretical design of any system is only the very 
beginning of its implementation. This thesis was intended to 
be the very beginning. There are still many questions about 
CSS left unanswered. Some include: 

• Which types of events would benefit most from coordination 
using a CSS? 

• What is the best way to manage interdependencies within 
the schedule generator? 

• Could a coordination system that learns be developed? 

• To what extent would a robust CSS alleviate the need for 
training? 

• What contribution to the development of CSS will come from 
the study of social sciences? 

While this thesis has only scratched the surface of the many 
issues surrounding CSS development, it has provided a useful 
framework within which to perform the design and analysis of 
coordination systems. Further research into the lower level 
design of the individual modules will yield great benefits. 
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